Method for generating a schedule for mixed critical computer networks

ABSTRACT

A method for generating a schedule for the transmission of time-triggered, TT, messages in a network, wherein said network communicates TT messages according to said schedule and based on a global, network-wide time, wherein said network communicates rate-constrained, RC messages, wherein for each of said RC messages real-time requirements are provided, wherein the method comprises: Step 1: setting the transmission time of all TT messages which are communicated in the network, and Step 2: executing a search function to find a set of TT transmission times so that the real-time requirements of all RC messages are fulfilled, and when all real-time requirements or at least real-time requirements for defined RC messages are fulfilled, generating in Step 3: the schedule based on the transmission times retrieved in Step 2, or executing Step 2 again when not all real-time requirements or not all real-time requirements for the defined RC messages are fulfilled.

CROSS-REFERENCE TO RELATED APPLICATIONS

This disclosure claims priority to and the benefit of EP PatentApplication No. 19196173.9, filed Sep. 9, 2019, which is herebyincorporated by reference herein in its entirety.

FIELD

The invention relates to a method for generating a schedule for thetransmission of time-triggered, TT, messages in a network, for examplein a TTEthernet or TSN network, wherein the network comprisescomponents, for example nodes and starcouplers, wherein components ofsaid network communicate time-triggered messages according to saidschedule and based on a global, network-wide time, and wherein saidcomponents communicate rate-constrained, RC messages, wherein for eachof said RC messages real-time requirements are provided.

Furthermore the invention relates to a computer network, for example aTTEthernet or TSN network, wherein the network comprises components, forexample nodes and starcouplers, wherein components of said networkcommunicate time-triggered messages according to said schedule and basedon a global, network-wide time, and wherein said components communicaterate-constrained, RC messages, wherein for each of said RC messagesreal-time requirements are provided.

For example said components, in particular said nodes and star couplers,are arranged in a multi-hop fashion.

BACKGROUND

A computer network, for instance an IEEE 802.3 Ethernet (Institute ofElectrical and Electronics Engineers 2018) or TSN (Institute ofElectrical and Electronics Engineers 2017), can carry both scheduled andunscheduled communication messages, whereby scheduled communication(time-triggered or TT) messages are transmitted from a sending entity(component) to one or more receiving components (entities) at predefinedpoints in time in a network-wide well-defined time, while unscheduledcommunication messages are transmitted according to other criteria.Appropriate transmission protocols and mechanisms for message handlingand message prioritization can be applied, whereby it is ensured that nointerference of any scheduled or unscheduled communication message withany given scheduled communication message can occur.

Non-scheduled messages can be of two types: Rate-Constrained (RC) andBest-Effort (BE). RC traffic is sent with a minimum interarrival-timecalled BAG (Institute of Electrical and Electronics Engineers 2018) andtypically has real-time requirements on the maximum allowed end-to-endlatency and jitter. BE traffic does not have any real-time requirements.

In mixed-criticality networks (i.e., networks that have TT, RC and BEtraffic), the communication schedule for TT messages influences thetimely behaviour of RC and BE messages due to the fact that TT messageshave higher priority over RC and BE messages and are sent first, hencedelaying the transmission of RC and BE messages. Hence, the Tcommunication schedule may adversely affect the transmission of RCmessages such that they do not adhere to their real-time requirements.

SUMMARY

It is an objective of the invention to generate a schedule for networks,in which at least time-triggered messages and RC messages arecommunicated.

This object is achieved a method as mentioned above, wherein accordingto the invention said method is characterized by the following steps:

-   -   Step 1: setting the transmission time of all TT messages which        are communicated in the network, and    -   Step 2 executing a search function to find a set of TT        transmission times so that the real-time requirements of all RC        messages are fulfilled, and in the case, that all real-time        requirements or at least real-time requirements for defined RC        messages are fulfilled, generating in a    -   Step 3: the schedule based on the transmission times retrieved        in Step 2,    -   or executing Step 2 again in case that not all real-time        requirements or not all real-time requirements for the defined        RC messages are fulfilled.

For example, it may be provided that the real-time requirements demandor at least demand that the end-to-end travel time for defined RC flows,in particular for each RC flow fulfills its deadline.

According to the invention it may be provided to evenly space the Ttransmission times to reduce the impact of TT flows on RC flows so thatfor example the RC worst-case end-to-end travel times (time needed for amessage to go from its source to its destination) may be smaller thanthe deadlines.

Further advantages of the invention, which alone or in any arbitrarycombination may be realised, are described in the following:

-   -   The transmission times of all the TT messages may be set, in        particular for one TT flow after the other, using an        optimization function, preferably with an SMT-solver.    -   The real-time requirements for the RC messages may comprise an        end-to-end delay bound, and wherein the search function in Step        2 is loop based with the following loop-steps:        -   loop-step 1: comparing the worst-case end-to-end delay bound            of each RC flow with its corresponding deadline, wherein in            case that the delay bound is larger than the corresponding            deadline according to the RC requirements for said RC flow,            the next two loop steps are executed:        -   loop step 2 identifying TT transmission times to be            modified, and        -   loop step 3: computing of the transmission times of the            selected TT flows in loop step 2, preferably for each output            port of the flow path of a selected TT flow, for example            using an optimization function within the SMT-solver.

Here, loop step 2 will help to guide the search to the most promisingparts of a solution space.

If in loop step 1 the delay bound is smaller, a solution is found andthe search stops.

-   -   A record of the previously explored option can be kept, which        may be used to guide the search into unexplored parts of the        solution space and/or to be used as an additional stopping        condition for the search.    -   The search function (search algorithm) comprises an        identification of TT transmission times to be modified based on        a Network Calculus framework and an arrival curve in each output        port, which represents the maximum amount of data that can        arrive in an output port in any time interval of TT traffic        detailed. This method is detailed in L. X. Zhao, H. G. Xiong, Z.        Zheng, and Q. Li. Improving worst-case latency analysis for        rate-constrained traffic in the time-triggered Ethernet network.    -   A staircase curve for each output port of the network crossed by        TT flows may be computed, wherein the staircase curves are        approximated by linear curves, and wherein TT flows having an        impact, in particular a large impact on RC flows, in particular        on the real-time requirements of the RC flows, are identified by        intersecting a staircase curve and its linear approximation, the        flow most likely to have a large impact on RC flows is        identified (see also detailed description under “findBestFlow(        )”). This computing is detailed for example in L. X. Zhao.    -   The computation of the TT transmission times may be executed        with the use of an optimization function, which preferably is        added within the SMT-solver, and wherein a set of TT flows with        a hyper-period, HP, which is the least common multiple of all        flow periods of all TT flows, is considered, and wherein for        each output port, where TT flows occur, a gain function is        defined. Defining a gain function may guide the search of a good        transmission time, i.e. a time which will have a low impact on        RC end-to-end delays.    -   For the computation of transmission times, gain functions        between the already scheduled TT frames may be determined,        wherein with t^(end) _(k) being the end of a frame transmission        and t^(start) _(k+1 being) the start of the next transmission,        for each TT frame already scheduled, the gain functions are        determined by:

${\forall{t_{k}^{end} \leq t < \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t - t_{k}^{end}}}$${\forall{t_{k + 1}^{start} \geq t \geq \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t_{k + 1}^{start} - t}}$

-   -   wherein for each period of a flow of interest, preferably in        each output port, the gain functions are summed and the abscise        of the maximum value of the summed gains is selected, preferably        by the SMT-solver, as the transmission time in the output port.    -   It may be provided that only gain functions in the acceptable        times are summed, and wherein the resulting summed gain        functions are approximated, in each output port, in that the        abscise of the maximum value of the approximated gains is        selected, preferably by the SMT-solver, as the transmission time        in the output port. “Acceptable” time means time intervals where        no frame are already scheduled and wherein the time interval is        large enough to schedule a current frame. Accordingly, only a        maximum of two linear functions per interval can be kept.

In particular, the preservation of real-time properties or thefulfilling of real-time requirements refers to the guaranteed end-to-endlatency for the periodic transmission of messages between one sendernode and one or several receiver nodes, via well-defined communicationchannels, known as virtual links (VLs). The end-to-end latency isbounded if the transmission methods ensure that the messages aretransmitted at their scheduled point in time (within a small deviationderived from the clock synchronization imprecision) without occurring incontention with other scheduled or unscheduled transmissions.

The second step of the proposed method (in particular the searchalgorithm) may relate to changing an existing schedule for TT messagetransmissions, whereby the changes preserve the transmissions of alreadyscheduled TT messages and guarantee the real-time requirements of RCmessages.

In the context of this text the term “transmission times” of a TTmessage refers to transmission points in time/transmission instants, inparticular the earliest transmission instant/point in time at which saidTT message is transmitted. In particular, these are the earliest startsof transmissions allowed inside an output port, meaning the transmissionof a message will start as soon as possible after this point in time(the transmission can sometimes be delayed by other messages).

In particular, it is provided that (a) the transmission of TT messagesdoes not interfere with the transmission of other already established TTmessage transmissions; (b) the modification will not invalidate thereal-time requirements of such TT messages, and (c) the modifiedtransmission times of such TT messages allows RC messages to meet theirreal-time requirements.

In the network, preferably each node is connected to at least one starcoupler via a physical link. The connection is realized via physicalports on each of the devices. Nodes and star couplers have a limitednumber of ports, and therefore a maximum number of connecting physicallinks.

All nodes and star couplers share a common notion of time by means ofe.g. a time synchronization protocol like, for example, SAE AS6802 (SAEInternational 2011) or IEEE 802.1AS (Institute of Electrical andElectronics Engineers kein Datum).

Nodes communicate to each other by exchanging periodic time-triggered(TT) messages and rate-constrained (RC) messages.

A time-triggered message, characterized by a virtual link, has thefollowing attributes:

-   -   A sender node    -   One or several receiver nodes    -   A period    -   A maximum message size    -   A maximum end-to-end latency

A rate-constrained message, characterized by a virtual link, has thefollowing attributes:

-   -   A sender node    -   One or several receiver nodes    -   A minimum inter-arrival time    -   A maximum message size    -   A maximum end-to-end latency    -   A maximum jitter

The transmission of time-triggered messages may be characterized bytheir VLs and follows a schedule. Each VL is routed through the network.The routing process consists of finding a multi-hop network pathconnecting the sender node with each of the receivers (using, forexample Steiner Trees [Steiner, W. 2010. “An evaluation of SMT-basedschedule synthesis for time-triggered multi-hop networks.” RTSS].

For each physical link on the network path, a frame may be scheduled forperiodic transmission according to the respective message attributes.

Frames are scheduled sequentially such that the transmission point intime of any intermediate hop is not scheduled before the previous frameis received at the respective hop.

The schedule point in time of each frame may be an offset relative tothe period, in which the frame will be transmitted. The transmissionsare repeated periodically at the given offset.

The end-to-end latency is guaranteed if the last frames are received atthe receiver nodes within the maximum end-to-end latency.

During operation, nodes and star couplers transmit TT frames on eachlink at their scheduled points in time (within a given time precision)following the schedule for the respective link.

The schedule for a link comprises the scheduled points in time for allTT frames scheduled on that link.

The schedule repeats cyclically according to the network cycle,typically the least common multiple of the periods of all VLs.

RC frames are sent whenever there is no higher-priority TT message readyto be sent. Hence the timely behaviour of RC messages is influenced bythe TT transmission schedule.

The generation of a network schedule comprising the periodictransmission of frames for all virtual links satisfying their end-to-endlatency and without contention is a complex operation. Therefore, it istypically calculated and distributed offline (prior to operation). Thisimplies that the information regarding the communication needs betweennodes is also available prior to operation.

The transmission of time-triggered messages per se as characterizedabove during operation is prior art.

Given a time-triggered computer network as described above in operationthe invention for example relates to a method to identify the TTmessages that adversely impact the RC message transmission and to modifythe transmission times of said TT messages in order to guarantee RCreal-time requirements (these requirements may comprise the end-to-endlatency, and/or jitter), wherein the transmission points in time of therespective TT frames are modified without altering the real-timeproperties (end-to-end latency) of the already scheduled transmissionsand the real-time properties of said new VLs are guaranteed.

Additionally, the invention refers to a computer program comprisingprogram code means for performing a method according to the inventionwhen said program is run on a computer.

Finally, the invention relates to a computer program product comprisingprogram code means stored on a computer readable medium for performing amethod according to the invention when said program product is run on acomputer.

In another embodiment, the invention relates to a method for generatinga schedule for the transmission of flows in a network, said flowsincluding time-triggered, TT flows, and rate-constrained, RC flows, eachsuch flow comprising messages, respectively TT messages and RC messages,wherein the network comprises components, like nodes and starcouplers orother components that communicate messages between different componentsin the network, wherein the network is a time-triggered, TT, network ora time-sensitive, TSN network, and wherein the components of saidnetwork communicate time-triggered messages according to said scheduleand based on a global, network-wide time, and wherein said componentscommunicate rate-constrained, RC messages, wherein for each of said TTand RC messages real-time requirements are provided, and wherein foreach of the RC messages, the real-time requirement provided comprises afirst requirement which is a worst-case end-to-end delay bound for thetransmission of the message.

The method may comprise the steps of

-   -   A1: a first search for a set of TT transmission times satisfying        a first condition, the first condition being that with the set        of TT transmission times applied to the TT messages, that the        real-time requirements of all TT messages are fulfilled,    -   A2: a first determination, applied to the set of TT transmission        times found during the first search, of whether the found set of        T transmission times satisfies a second condition,        the second condition being that with the set of transmission        times applied to the TT messages, that the real-time        requirements of the messages of a first set of flows are        fulfilled, wherein the first set of flows is a subset of the RC        flows,        and wherein in the case where the found set of TT transmission        times does not satisfy the second condition, the step A1 that        follows include steps:    -   A11: a first selection of a second set of TT transmission times        among the found set, the second set of TT transmission times        being the TT transmission times that need to be modified in view        of fulfilling the real-time requirements of the first set of        flows,    -   A12: a computation of modified transmission times of the second        set of T transmission times, the result of the computation being        a new set of TT transmission times fulfilling the first        condition for all TT messages.    -   A3: repetition, in a case where the found set of TT transmission        times does not satisfy the second condition, of the steps A1 to        A3 until a set of transmission times is found that satisfies the        second condition, and    -   A4: generation of the schedule such that the schedule includes        the found set of TT transmission times.

It may be provided that the first search, A1, includes a secondselection for choosing, among a plurality of sets of TT transmissiontimes satisfying the first condition, the one of the plurality of setsof TT transmission times satisfying the first condition that optimizes afirst optimization function, wherein the first optimization function ischecked with a solver, like a Satisfiability Modulo Theory, SMT, solver,or any other solver.

It may be provided that the step A11 comprises the steps

-   -   A111: a computation of a hyper-period, HP, which is the least        common multiple of all flow periods of all TT flows,    -   A112 a third selection of the first set of flows on the basis of        the hyper-period, and    -   A113: for each output port identified as being the output port        of a node of the network such that at least one of the flows of        the first set of flow passes through the considered output, a        computation of a gain function.

It may be provided that, step A113 comprises the steps of

-   -   A1131: the computation of gain functions for already scheduled        TT frames is according to a following formula, wherein with t-w        being the end of a frame transmission and t^(start) _(k+1 being)        the start of the next transmission:

${\forall{t_{k}^{end} \leq t < \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t - t_{k}^{end}}}$${\forall{t_{k + 1}^{start} \geq t \geq \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t_{k + 1}^{start} - t}}$

wherein the step A12 comprises the steps of:

-   -   A121: for at least one of the TT flows, a computation of at        least one of the TT transmission times based on the gain        functions computed for the already scheduled TT frames, which        step A121 comprises the steps, for each period of the considered        flow and for at least one output port through which the        considered flow passes:    -   A1211: computing a total gain function by summing the gain        function of all the flows passing through the considered output        port, and    -   A1212: selecting as a TT transmission time in the output port a        time t0 for which the value of the total gain function is        maximum over the period of the considered flow.

It may further be provided that step A1211 comprises

-   -   A12111: computing the gain function only for a period of the        considered flow, and    -   A12112: approximating the total gain functions.

It may be provided that step A1 is guided by an algorithm based on aNetwork Calculus, NC, framework.

It may be provided that step A2 includes storing a record of the set ofTT transmission times found.

It may be provided that the step A2 comprises steps:

-   -   A21: a computation, for the found set, of a staircase curve for        each output port identified as being the output port of a node        of the network such that the first set of flow passes through        the considered output port,    -   A22: for each output port considered in step A21, an        approximation of the staircase curve by a linear curve,    -   A23: for each output port considered in step A21, an        intersection of the staircase curve with the linear curve,    -   A24: for an output port considered in step A21, determining an        impact of a flow passing through the output port on the basis of        the intersection of the staircase curve with the linear curve,        and        wherein the first selection in step A11 includes identifying one        of the flows of the first set of flows on the basis of the        impact of said flow being quantified as large.

The invention refers also to a computer network, wherein the network isa time-triggered, TT, network or a time-sensitive, TSN network, whereinsaid computer network comprises components, like nodes and starcouplersor other components that communicate messages between differentcomponents in the system,

wherein said components communicate flows including time-triggered, TTflows, and rate-constrained, RC flows, each such flow comprisingmessages, respectively TT messages and RC messages,and wherein components of said network communicate time-triggeredmessages according to a schedule and based on a global, network-widetime, and wherein said components communicate rate-constrained, RCmessages, wherein for each of said TT and RC messages real-timerequirements are provided, wherein the network is adapted to includemeans to generate a schedule generated with a method described above.

The invention further relates to a computer program comprising programcode means for performing the steps of the described method when saidcomputer program is run on a computer.

Finally the invention relates to a computer program product comprisingprogram code means stored on a computer readable medium for performingthe method when said computer program product is run on a computer.

BRIEF DESCRIPTION OF THE FIGURES

In the following, in order to further demonstrate the present invention,illustrative and non-restrictive embodiments are discussed, as shown inthe drawings, which show:

FIG. 1 an example of a time-triggered network,

FIG. 2 the periodic transmission of TT messages,

FIG. 3 a detailed representation of the transmission cycle depicted inFIG. 2,

FIG. 4 an example of computing of a TT flows arrival curve,

FIG. 5 the computation of gain functions,

FIG. 6 the approximation of a gain function,

FIG. 7 an example of a switch architecture,

FIG. 8 an example of a traffic model, and

FIG. 9 an example of a use case.

DETAILED DESCRIPTION

We discuss some of the many implementations of the invention next. Ifnot stated otherwise, all details described in connection with aspecific example are not only valid in connection with this example, butapply to the general scope of protection of the invention.

FIG. 1 shows an example of a time-triggered network which comprises orconsists of three time-triggered star couplers (i.e. switches) 110, 120,and 130, and six nodes (i.e. end systems) 111, 112, 121, 122, 131, 132.All systems are connected via lines (which preferably are bidirectional)as shown in the figure and have a common time-base, for example asdefined in TTEthernet (Institute of Electrical and Electronics Engineers2018). Time-triggered (TT) messages are transmitted following apre-configured global cyclic schedule in coexistence with other traffic(rate-constrained and best effort traffic).

A global distributed schedule determines exact points in time for thetransmission of TT messages between the network systems (also denoted as“devices” or “components”; such systems are, for example, the mentionednodes and star couplers), in a way that the transmissions through theshared lines is realized without contention. The calculation of theschedule is computationally intense, and therefore it is typicallyperformed offline (i.e. prior to the system start-up) and distributedfully or partially to each of the systems of the network. At run-time,the global time base, within a known precision, is available to allsystems, and used to execute the schedule in a cyclic and coordinatedmanner.

Non-scheduled traffic is transmitted during the sparse time betweenscheduled transmissions, in a way that the interference to scheduledtransmissions is either avoided or bounded to a known maximum delay.

The transmission of scheduled messages is logically organized accordingto the concept of virtual links (VL). A VL defines one sender node (i.e.end system) and one or multiple receivers, as well as a physical pathbetween them. The transmission of messages in a VL originates at thesender and propagates through the physical path (communication lines)until the receiver end system nodes are reached. Each of thesepropagation steps implies a scheduled transmission after the receptionof the previous message. Additional constraints may be provided for VLs,for example a maximum end-to-end transmission deadline, referring to themaximum allowed interval for the propagation of messages—from sender toreceiver(s).

A time-triggered message, characterized by a virtual link, has thefollowing attributes:

-   -   A sender node    -   One or several receiver nodes    -   A period    -   A maximum message size    -   A maximum end-to-end latency

A rate-constrained message, characterized by a virtual link, has thefollowing attributes:

-   -   A sender node    -   One or several receiver nodes    -   A minimum inter-arrival time    -   A maximum message size    -   A maximum end-to-end latency    -   A maximum jitter

Let vl_(a) be a TT virtual link with sender node 121 and receiver node131 in the network depicted in FIG. 1. The network path is hencecomposed by the sequence {121, 120, 130, 131}, as extracted from FIG. 1.Let the period as well as the end-to-end delay of vl_(a) be 100 ms.

FIG. 2 illustrates the periodic transmission of TT messages from vl_(a)within the transmission cycles of the three nodes conforming therespective network path (subfigures 150, 160, and 170). Note that inthis example only the transmission events are scheduled, hence node 131,the receiver, does not appear. Respectively, 150 represents the cyclictransmission of messages from vl_(a) in node 121, 160 that in node 120,and 170 in node 130. Each of the subfigures represent a time cycle of100 ms starting from the top most point in time (200, 300, and 400) andprogressing clockwise. The clock is synchronized globally at everycycle; hence the time progression is homologous for all systems, withina known synchronization precision.

In essence, at time 200 a transmission event for a TT message of vl_(a)occurs at node 121 which initiates the transmission of a message takingplace until time 210. Node 120 receives the message and transmits thesucceeding message at time 310, being the transmission finished by, atmost, 320. Similarly, node 130 transmits a succeeding message at 410,finishing by 420. This transmission cycle repeats endlessly in acoordinated manner.

Note that event 310 can only occur after event 210, as the messagetransmission in node 120 directly depends on the previous reception ofthe message transmitted by node 121. Analogously, event 410 depends onthe occurrence of event 320. In essence, for the second and followingmessages propagated along the network path of a VL, the transmission canonly be initiated after the previous message of the VL has arrived atthe current node.

FIG. 3 provides a detailed representation of the transmission cycledepicted in FIG. 2, including all other scheduled transmissions in thesame communication line for node 120 (dark gray), in addition to thoseof vl_(a) (light gray) already depicted in FIG. 2. We observe thatadditional transmissions occur between events 301-310, and 320-321. Notethat a transmission cycle defines the outgoing transmissions of amessage towards one single communication line of the respective node(often referred as ports). Therefore, 180 depicts only the transmissioncycle of node 120 for the communication line between nodes 120 and 130.Also note that similarly to the sequential transmissions depicted inFIG. 2, the transmissions of messages shown in FIG. 3 have dependenciesto previous transmissions from nodes 121, 122 or 110 as part of VL pathstraversing node 120.

The schedule of the TT frames on the timeline may have a major impact onthe delays experienced by RC flows since TT traffic has a higherpriority. Typically, the end-to-end latency of RC messages in suchnetworks is analyzed through methods like network calculus (A. VanBemten, W. Kellerer. 2016. Network Calculus: A Comprehensive Guide. TUM.https://mediatum.ub.tum.de/doc/1328613/1328613.pdf). An extension ofthis analysis which considers the TT message schedule is presented in. Apreferred timing analysis, which may be used in this invention, is basedon the Network Calculus framework [L. Zhao, P. Pop, Q. Li, J. Chen, andH. Xiong, “Timing analysis of rate constrained traffic in TTEthernetusing network calculus,” Real-Time Systems, 2017.] which may be used tocompute upper delay and backlog bounds. These bounds depend on thetraffic arrival described by a so-called arrival curve α, whichrepresents the maximum amount of data that can arrive in any timeinterval, and on the resource availability described by a curve, theso-called minimum service curve β, which represents the minimum amountof data that can be sent in any time interval.

Proposed Method

The schedule of the TT frames on the timeline may have a major impact onthe delays experienced by RC flows since TT traffic has a higherpriority. According to the present invention it is checked that the RCend-to-end latencies computed with the current T schedule are fulfillingthe RC deadlines, using a feedback loop that preferably uses an RCnetwork calculus analysis (A. Van Bemten, W. Kellerer. 2016. NetworkCalculus: A Comprehensive Guide. TUM.https://mediatum.ub.tum.de/doc/1328613/1328613.pdf) to check that the RCend-to-end latencies computed with the current TT schedule arefulfilling the RC deadlines. If the RC latencies are larger than the RCdeadlines, the problematic TT messages are rescheduled.

Evenly spacing out T message placement may lead to a lower impact on RCmessage end-to-end latencies. Hence, it may be provided that anoptimization metric is built that tries to evenly space out TT frames onthe timeline and use optimization objectives to drive the modificationof the TT message schedule.

Firstly, all the TT flows are scheduled, preferably according to saidoptimization metric. Secondly, an RC analysis is provided to determineif the RC traffic fulfills the deadline requirements. If this is thecase, the method/algorithm stops. If this is not the case, the algorithmidentifies the TT messages most likely to be causing delays and attemptto find a better offset, i.e., a modification of transmission times ofidentified TT messages, preferably using an optimization metric. Thissecond step is repeated until an appropriate schedule is found or astopping condition is reached.

The search may stop when a set of offsets fulfilling the deadlineconditions is found or when the search algorithm has tried to rescheduleall the possible flows without finding an unexplored set of offsets.

Identification of the TT Message to Reschedule (FIG. 4)

The impact of TT flows may be represented by an arrival curve of the TTtraffic, which may be computed using formulas detailed in (L. Zhao, P.Pop, Q. Li, J. Chen, and H. Xiong, “Timing analysis of rate constrainedtraffic in TTEthernet using network calculus,” Real-Time Systems, 2017).The main aspect is to compute the impact of TT flows in all possiblesituations and keep the maximum values, as illustrated in FIG. 4. Thedotted lines in FIG. 4 are the different situations and the plain linestaircase represents the maximum of the dotted lines, representing thefinal TT flows maximum arrival curve. From this staircase arrival curve,a linear arrival curve may be approximated. The rate [the increase ofthe linear curve] of the linear curve is the same as the rate of thestaircase curve over a period. Concerning the initial burst [the valueof the linear curve at t=0] of the linear curve, it is computed such asthe linear curve is always superior or equal to the staircase curve,with at least one intersection, as illustrated in FIG. 4. As a result,by modifying the value of the offset associated to the staircaseintersection point, the value of the burst of the linear curve may bereduced, and consequently, the impact of TT traffic on RC flows isreduced. A so-called diversification list may be used to keep track ofTT flows that have already been explored and changed in order not to runinto an endless loop by trying to modify the schedule of the same TTflow(s). To select the flow most likely to have the most impact, thenumber of times a flow is an intersection can be computed and the flowwith the most occurrences that is not in the diversification list may beselected. Finally, if no flow has been found, the first flow in the listof TT flows that is not in the diversification list will be selected.

Generation of the TT Offsets (FIG. 5)

To compute the offset leading to a minimum impact of TT flows on RCflows, it may be provided that the frames are spread over a hyperperiod(that is the least common multiple of all scheduled TT message periods),in order to reduce the initial burst of the aggregated TT flows. Here,the period is 10 and the hyperperiod HP is 40.

To achieve this goal, in particular in each output port with TT flows,gain functions between the already scheduled TT frames may be defined,as illustrated in an example in FIG. 5. When looking at the time-line ofscheduled transmissions between 0 and the hyperperiod, we denote t_(k)^(end) to be the end of the transmission of a TT frame and t_(k+1)^(start) to be the start of the next transmission of a TT frame on thetime-line. For each TT frame k already scheduled (not including the TTframes of the TT flow identified as described above, which may bedenoted by TT flow i, the gain functions are determined by:

${\forall{t_{k}^{end} \leq t < \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t - t_{k}^{end}}}$${\forall{t_{k + 1}^{start} \geq t \geq \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t_{k + 1}^{start} - t}}$

For a selected TT flow from the identification step its transmissiontimes along the route may be modified as follows:

-   -   the at least one, preferably all of the following correctness        conditions have to be kept:        -   Contention-Free Constraints        -   Path-Dependent Constraints        -   Simultaneous Relay Constraints        -   End-to-end Transmission constraints        -   Application Level constraints        -   Protocol-Control Flow Constraints        -   Domain-Specific constraints        -   An optimization condition for the frames of the identified            TT flow that drive the placement of the frames to be as            close as possible to the maximum gain for that frame is            added.

The above conditions are described in detail in [Steiner, W. 2010. “Anevaluation of SMT-based schedule synthesis for time-triggered multi-hopnetworks.” RTSS.].

-   -   Optionally, a condition for each port that the new offset is        different from the old offset may be added.

Approximation (FIG. 6)

The method presented above may require a large number of optimizationfunctions. In between each two scheduled TT frames, a number ofoptimization functions is necessary to define the two linear parts ofthe gain, i.e., to define the upper and lower bounds of the new offsetand the value associated with the gain. When the number of TT flowsincreases, so does the number of assertions needed, resulting in anincreased runtime of the scheduler.

Accordingly, the following may be provided: only a period Ti of a flow i(the flow to be rescheduled) is considered and the values excluded bythe currently scheduled frames are computed, i.e., if a frame is beingtransmitted, or if the inter-frame gap is too small to transmit theframe of flow i. Then, the gains, preferably only on the acceptabletimes, are summed up, as illustrated in FIG. 6. Finally, to furtherreduce the number of linear parts of the gain function (which meansreducing the number of assertions and hence the computation time), theremaining gain functions may be approximated to keep only a maximum oftwo linear functions per interval [between two already scheduled framesor between 0 and a frame or between a frame and the hyperperiod (inparticular, between 0 and the end of the hyperperiod)], as illustratedin FIG. 6, here with Ti=10 and hyperperiod HP=40.

In the example described in FIG. 5 and FIG. 6, the number of assertionshas been reduced from 24 to 6, which should improve the timingperformances.

Detailed Explanation of an Example Method

In the following a concrete example of the method according theinvention will be explained. All details, even if they are in thecontext of this example described as mandatory, may be provided orimplemented in the most general scope of the invention.

1 Theoretical Background

1.1 TTEthernet

TTEthernet is an extension to standard Ethernet currently used inmixed-criticality real-time applications in the aerospace domain butalso in emerging industrial automation systems. TTEthernet featuresthree types of traffic that represent different criticality levels: TTtraffic (used for highly critical traffic with guaranteed end-to-endlatency and minimal jitter), RC traffic with deterministic quality ofservice (QoS) guarantees and non-critical traffic (i.e. BE traffic). TheTTEthernet [7] standard is based on the use of global timesynchronization to send Time Triggered (TT) frames at precise,predefined times (encoded in a local schedule table that is part of aglobally computed schedule) to ensure the lowest contention and delays.Hence, the TT flows are defined by their size, period, and offsets (thetimes their transmission should start) in each output port. Thesynchronization flows have the highest priority in TTEthernet networks,the next priority is used by the TT flows, the two next priorities areused by the AFDX RC_(HIGH) and

C_(LOW) traffic, respectively, while the remaining 4 lowest prioritiesare reserved for Best-Effort (BE) communication (cf. FIG. 7).

1.2 SMT-Based TTEthernet Schedule Synthesis

Here, we briefly describe, based on [11, 6, 10] the SMT-based approachfor computing communication schedules for TTEthernet.

Satisfiability Modulo Theories (SMT) is a well-known method, similar toSAT, used to check the satisfiability of first-order logical formulasbased on a background theory such as linear integer arithmetic (

) or bit-vectors (

) [1], [9]. Current state-of-the-art TTEthernet scheduling approaches[6], use SMT solvers for generating the static schedule by generatingassertions to the context of an SMT solver representing the necessaryand sufficient correctness conditions. The result of the SMT solver is asolution for the given constraints, representing values for the offsetsof individual frames on each device. Additionally, modern SMT solverslike Z3 [2] offer the possibility to include optimization criteria thatfind the optimal solution given minimization or maximizationcondition(s).

Our algorithm, which builds on top of the work in [11], uses SMT solversto find out the schedule for a network based on the inherent TTEthernettechnology constraints and optional user constraints. Steiner [11]proposes an incremental backtracking algorithm, which we alsoimplemented, that splits the scheduling problem in small increments,scheduling subsets of flows at a time. If a partial solution is foundfor the subset, additional frames and constraints are added until eitherthe complete schedule is found or a solution to a partial problem cannotbe found. In the case of in-feasibility, the problem is backtracked andthe size of the added subset is increased. In the worst case thealgorithm backtracks to the root, scheduling the complete set of framesin one step. Our algorithm adds each flow from the input to the SMTcontext in sequence following the algorithm described in [11]. We referthe reader to [11] for a description and formalization of thecorrectness constraints for the SMT-based TTEthernet scheduler which weuse in our method.

While the SMT-based approach retains the optimality property of SAT- orMiP-based solutions, the major downside is that the SMT solver acts as ablack box and we are only able to influence it by defining constraints(assertions) and optimization criteria. Moreover, we are constrained tothe expressiveness of first order logic. Hence, state-of-the-artSMT-based schedulers only take into account the TT flow constraints. Asa result, the RC traffic can be strongly impacted by the placement ofthe scheduled TT frames and miss their required deadlines.

We propose a feedback-based approach that attempts to drive the SMTsolver via optimization criteria towards placing TT frames on thetimeline such that RC traffic will adhere to the latency and backlogrequirements.

Please note that, while the proposed method is tailored to TTEthernet,the main feedback-based approach can also be used in Time-SensitiveNetworks (TSN) which is the new standardized deterministic Ethernetsolution for industrial communication systems. For TSN, existingSMT-based solutions (e.g. [10]) can be extended using our proposedmethod to consider AVB traffic shaped by CBS by including the networkcalculus-based AVB analysis results from [12].

1.3 Network Calculus

The timing analyses detailed in this paper are based on the NetworkCalculus framework [8] which is used to compute upper delay and backlogbounds. These bounds depend on the traffic arrival described by theso-called arrival curve α, which represents the maximum amount of datathat can arrive in any time interval, and on the resource availabilitydescribed by the so-called minimum service curve δ, which represents theminimum amount of data that can be sent in any time interval.

Definition 1 (Arrival Curve) [8] A function α(t) is an arrival curve fora data flow with an input cumulative function A(t), i.e., the number ofbits received until time t, iff:

∀t,A(t)≤(A⊗ ¹α)(t)

¹f⊗g(t)=info_(0≤s≤t){f(t−s)+g(s)}

Definition 2 (Strict minimum service curve) [8] The function β is theminimum strict service curve for a data flow with an output cumulativefunction A*, if for any backlogged period]s,t]²: A*(t)−A*(s)≥β(t−s)²]s,t] is called backlogged period if A(τ)−A*(τ)>0,∀τ∈]s,t]

To compute the main performance metrics, we need the following results:

Theorem 1 (Performance Bounds) [8] Consider a flow F constrained by anarrival curve α crossing a system S that offers a minimum service curveβ. The performance bounds obtained at any time t are:

Backlog³ : ∀t:q(t)≤v(α,β)

Delay⁴ : ∀t:d(t)≤h(α,β)

Output arrival curve⁵: α*(t)=(αØβ)(t)

³v: maximal vertical distance⁴h: maximal horizontaldistance⁵fØg(t)=sup_(s≥0){f(t+s)−g(s)}

Theorem 2 (Concatenation-Pay Bursts Only Once) [8] Assume a flowcrossing two servers with respective service curves β₁ and β₂. Thesystem composed of the concatenation of the two servers offers a servicecurve β₁⊗β₂.

Theorem 3 (Left-over service curve) [3] Consider a system with thestrict service curve β and m flows crossing it, f₁, f₂, . . . , f_(m).The maximum packet length of f_(i) is l_(i,max) and f_(i) isα_(i)-constrained. The flows are scheduled by the NP-SP policy, wherepriority of f_(i)>priority of f_(j)⇔i<j. For each i∈{1, . . . , m}, thestrict service curve of f_(i) is given by⁶:

$( {\beta - {\sum\limits_{j < i}\alpha_{j}} - {\max\limits_{k \geq i}l_{k,\max}}} )_{\uparrow}$

The traffic contracts are generally enforced using a leaky-bucketshaper, i.e., the traffic flow is (r,b)-constrained where r and b arethe maximum rate and burst, and the arrival curve is α(t)=r·t+b. Acommon model of the minimum service curve is the rate-latency curveβ_(R,T), defined as β_(R,T)(t)=R·(t−T)⁺, where R is the outputtransmission capacity, T is the system latency, and (x)⁺ denotes themaximum between x and 0. The resulting output arrival curve is then:α*(t)=r·(t+T)+b ⁶g_(↑)(t)=max{0,sup_(0≤s≤t)g(s)}

An improvement of the leaky bucket shaper is to take into account thelink capacity of the input ports in order to obtain a more accurateinput arrival curve of the flows [5]. For example, a flow arriving witha maximum burst b and rate r, from a link with a capacity C_(in), has aninput arrival curve α(t)=min(C_(in)·t, r·t+b).

Extensions for the RC traffic class analysis for TTEthernet thatconsider the impact by the TT traffic class schedule have beenintroduced in [14, 13, 4].

2 Feedback Loop

An optimal solution would be to integrate the Network Calculus frameworkwithin the SMT solver to directly consider the constraints of the RCtraffic. However, this is not possible due to the non-linearity ofNetwork Calculus. In particular, the computation of the arrival curve ofTT frames as described in [14] make use of several minimizations,maximizations and upper-bound values to compute the overall arrivalcurve of TT flows.

The current state-of-the-art SMT-based schedulers do not consider RCflows. However, the placement of the TT frames on the timeline may havea major impact on the delays experienced by RC flows since TT traffichas a higher priority. The main idea of our proposal (described in moredetail below) is to use a feedback loop that uses the RC networkcalculus analysis to check the TT schedule and, if necessary, rescheduleproblematic flows.

First all the TT flows are scheduled using the optimization function ofthe SMT-solver to spread the TT frames. Our observation is that evenlyspacing out TT frame placement leads to a lower impact on RC flows.Hence, we build an optimization metric that tries to evenly space out TTframes on the timeline and use optimization objectives to drive thescheduling and rescheduling of TT flows via the SMT solver.

Secondly, the RC analysis is called to determine if RC traffic fulfillsthe deadline requirements. If this is the case, the algorithm stops. Ifthis is not the case, the algorithm identify the flow most likely to becausing delays and attempt to find a better offset, i.e., reschedules,using the optimization function of SMT.

This second step is repeated until an appropriate schedule is found or astopping condition is reached.

The additional advantage of such a solution is that it is complementaryto the existing implementation and can be readily integrated intoexisting tools. It does not require modification of the existingconstraints, just the addition of optimization objectives and theimplementation of the feedback loop.

2.1 General Algorithm

The general algorithm is detailed in Alg. 1. To modify the values of theoffsets, we propose to add an optimization constraint to the SMTscheduler, implemented in the function smtComputeOffset(flow) in Section1.2.3. In particular, we propose two methods for the computation of theoptimization function. They are detailed in Sections 1.2.4 and 1.2.5.

First, in Ag. 1, we set an initial offset for each flow (ranked fromsmallest to largest period) using smtComputeOffset(flow), from Line 1 toLine 3. Then, we check whether the RC deadlines are fulfilled in Line 4.If it is not the case, we attempt to modify the offset of a flowselected by the function findBestFlow( ) (describe in Section 1.2.2), inLines 8 and 9.

If the new set of offsets has already been explored (Line 10), we use awhile loop to explore possible offsets until all the flows have beentested or a new set has been found (Line 11). While no acceptablesolution is found in Line 11, we add the flow to the diversificationlist, look for a new flow that is not in the diversification list, andcompute the new offsets as before (Lines 12 to 15). If the new set ofoffsets has not already been explored, then the diversification list isreset (Lines 16 to 18). Finally, we check if the RC deadlines are nowfulfilled and update the list of explored offsets (Lines 19 and 20).

Algorithm 1: General algorithm Require: flows_(TT),flows_(RC)  1: forflow in flows_(TT) do  2:  smtComputeOffset(flow)  3: end for  4:rcDeadlinesFulfilled=computeRCDelays(flows_(RC))  5:listExploredOffset= 

 6: diversification= 

 7: while rcDeadlinesFulfilled==False and diversification.size <  flows_(TT).size do  8:  flow = findBestFlow( )  9: smtComputeOffset(flow) 10:  if getCurrentOffsets( ) inlistExploredOffset then 11:   while getCurrentOffsets( ) inlistExploredOffset and   diversification.size < flows_(TT).size do 12:   diversification.add(flow) 13:    flow = findBestFlow(diversification)14.    smtComputeOffset(flow) 15:   end while 16:  else 17:  diversification== 

18:  end if 19:  rcDeadlinesFulfilled=computeRCDelays(flows_(RC)) 20: listExploredOffset.add(getCurrentOffsets()) 21: end while

2.2 findBestFlow( )

The impact of TT flows is represented by the arrival curve of the TTtraffic, which is computed using the formulas detailed in [14]. The mainidea is to compute the impact of TT flows in all the possible situationsand keep the maximum values, as illustrated in FIG. 4. The dotted linesare the different situations and the plain line staircase is the maximumof the dotted lines, representing the final TT flows maximum arrivalcurve, denoted α_(TT) ^(k)(t).

From this staircase arrival curve, we are able to approximate a lineararrival curve. The rate of the linear curve is the same as the rate ofthe staircase curve over a period. Concerning the initial burst of thelinear curve, it is computed such as the linear curve is always superioror equal to the staircase curve, with at least one intersection, asillustrated in FIG. 4. As a result, by modifying the value of the offsetassociated to the staircase intersection point, we may be able to reducethe value of the burst of the linear curve, and consequently, reduce theimpact of TT traffic on RC flows. The intersection points are computedwithin the findIntersections( ) function.

Algorithm 2: findBestFlow( ) Require: flows_(TT),flows_(RC),Data_(paths),diversification Ensure: bestFlow  1: listCard={ }  2: forflowTT in flows_(TT) do  3:  listCard[flowTT]=0  4: end for  5: forflowRC in flows_(RC) do  6:  for path in flowRC paths do  7:   for portin path do  8:    flowsTTInter=findIntersections( )  9:    for flowTT inflowsTTInter do 10:     listCard[flowTT]+=1 11:    end for 12:   end for13:  end for 14: end for 15: bestFlow=NULL 16: if not isEmpty(listCard)then 17:  bestFlow=findMaxCardinal(listCard,diversification) 18: end if19: while bestFlow==NULL or bestFlow in diversification do 20:  bestFlow= flows_(TT).getNext( ) 21: end while

To select the flow most likely to have the best impact (the algorithm isdetailed in Algo. 2), we compute the number of times a flow is anintersection (from Line 5 to 14) and we select the flow with the mostoccurrences that is not in the diversification list, in Line 17.Finally, if no flow has been found, we select the first flow in the listof TT flows that is not in the diversification list, in Lines 19 to 21.

2.3 smtComputeOffset( )

We consider a set of TT flows with a hyper-period HP (computed as theleast common multiple of all flow periods). Our goal is to define theoffset x of flow i with maximum frame sizes MFS_(i) and period T_(i).All the preexisting constraints from [11] are enforced. In this section,we only present the constraints added for the optimization of theoffsets. Additionally, if the flow has already been scheduled, we alsoadd the constraint that x must differ from the current offset.

We denote C_(out) the capacity of the output port. For each TT frame kalready scheduled, we define t_(k) ^(start) and t_(k) ^(end) the startand the end of the transmission. We have

$m_{k} = {\frac{t_{k}^{end} + t_{k + 1}^{start}}{2}.}$

The function newSymbolicInt( ) creates a symbolic variable that will beused as an unknown by the SMT solver.

In Alg. 3, for each port in each path of the TT flow i, we compute theconstraints defining the gains, then they are added to the existing SMTconstraints in Line 6. Finally offsets are computed by the SMT solver inLine 7. The computation of the new constraints in a port. (i.e. Line 4)is described in Algo. 4.

Algorithm 3: Constraint computation for a path of TT flow i Require: TTflow i, path Ensure: Offsets_(i) 1: sumGain=newSymbolicInt( ) 2:constraints=preexisting constraints from [11] 3: for port in path do 4: (constraints, sumGain)=computeConstraintInPort (TT flow i, constraints, sumGain, Data_(port)) 5: end for 6:constraints.add(maximize(sumGain)) 7: Offsets_(i)=smtSolve(constraints)

2.4 computeConstraintsInPort( ): Variant 1

To compute the offset leading to the minimum impact of TT flows on RCflows, we must spread the frames over the hyper-period in order toreduce the initial burst of the aggregated TT flows.

To achieve this goal, in each output port with TT flows, we define gainfunctions between the already scheduled TT frames, as illustrated inFIG. 5, with T_(i)=10 and an Hyper-period HP=40. We denote t_(k) ^(end)the end of a frame transmission and t_(k+1) ^(start) the start of thenext transmission. For each TT frame k≠i already scheduled, the gainfunctions are determined by:

${\forall{t_{k}^{end} \leq t < \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t - t_{k}^{end}}}$${\forall{t_{k + 1}^{start} \geq t \geq \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t_{k + 1}^{start} - t}}$

Alg. 4 describes the definition of the gain function illustrated in FIG.5. In particular, Line 7 defines the outer bounds of a triangle, Line 8(resp. Line 9) defines the right (resp. left) side of the triangle.

However, this method requires a large number of assertions since SMToptimization constraints can only be defined as linear curves in

. Hence, in between two frames,

Algorithm 4: Constraint computation in a port p:computeConstraintsInPort( ) Require: TT flow i, constraints, sumGain,Data_(p) Ensure: constraints, sumGain  1: x= newSymbolicInt( )  2:$J = \frac{HP}{T_{i}}$  3: for j in range(0,J) do  4:  gain_(j)=newSymbolicInt( )  5:  for frame k in TT flows do  6:   if t_(k)^(end) >= j · T_(i) and t_(k+1) ^(start) <= (j + 1) · T_(i) then  7:    $A = {{And}( {{{x + {j \cdot T_{i}} + \frac{{MFS}_{i}}{C_{out}}}<=t_{k}^{end}}\mspace{11mu},{t_{k + 1}^{start}<={x + {j \cdot T_{i}}}}} )}$ 8:    B = And(x + j · T_(i) >= m_(k) , gain_(j) = t_(k+1) ^(start) − x− j · T_(i))  9:    C = And(x + j · T_(i) <= m_(k) , gain_(j) = x + j ·T_(i) − t_(k) ^(end)) 10:    constraints.add(And(A, Or(B, C))) 11:   sumGain+ = gain_(j) 12:   end if 13:  end for 14: end for

6 assertions are necessary to define the two linear parts of the gain,i.e., to define the upper and lower bounds of x and the value associatedto the gain. When the number of TT flows increases, so does the numberof assertions needed, resulting in an increased runtime of the scheduler[6].

Consequently, we propose a second variant of the algorithm to reduce thenumber of assertions through preprocessing and hence improve the runtimeof our approach.

2.5 computeConstraintsInPort( ): Variant 2

The main idea of the improvement is to consider only the period T_(i) ofthe flow i and compute the values excluded by the currently scheduledframes, i.e., if a frame is being transmitted, or if the inter-frame gapis too small to transmit the frame of flow i. Then, the gains (only onthe acceptable times) are summed up, as illustrated in FIG. 6. Finally,to further reduce the number of linear parts of the gain function (whichmeans reducing the number of assertions and hence the computation time),we approximate the remaining gain functions to keep only a maximum oftwo linear functions per interval, as illustrated in FIG. 6, withT_(i)=10 and HP=40.

In the example described in FIG. 5 and FIG. 6, the number of assertionshas been reduced from 24 to 6, which should improve the timingperformances. In the next section, we will present experimental resultsto validate these concepts and assess the gain in performance betweenthe two variants.

3 Performance Analysis

In this section, we do a performance analysis based on a real-worlduse-case in order to compare the two selected variants of our solution.First, we present preliminary assumptions, e.g., the model of the flow,the TTEthernet switch and end-systems, and delay computations. Then,after presenting our case study, we do a comparison of the two methodsfor a TTEthernet network.

3.1 Preliminaries and Assumptions

Switch and End-System model: we consider the TTEthernet switcharchitecture described in FIG. 7. Th input port delay is the amount oftime necessary for a frame i to arrive at a rate C_(in):

$\frac{{MFS}_{i}}{C_{in}}.$

We consider the delay in the switch starts after the frame has beenfully received. The forwarding process is defined by a minimum(best-case) and maximum (worst-case) delay, denoted WCD_(fwd) ^(n), andBCD_(fwd) ^(n), in a switch or end-system n∈{sw, es}. All the flows areusing the shuffling integration policy in the switches and end-systems,i.e, the TT frames can be delayed by lower priority frames.

TTEthernet output ports: the impact of the TT traffic on RC traffic iscomputed using the input arrival curves proposed in [14]. Then, theservice curves are computed using Th. 3.

Traffic model: to compute the delay bounds within each node (outputport, switch sw or end-system es), we use Th. 1 under the followingassumptions: (i) staircase arrival curves for the traffic flows at theinput of node n. For a flow i, we define the Maximum Frame Size MFS_(i)and the Bandwidth Allocation Gap BAG_(i) (the period and generally alsothe deadline). The initial arrival curve sent by the traffic source

${\alpha_{I}(t)} = {\sum\limits_{i\; \in \; I}{{MFS}_{i} \cdot {\lceil \frac{t + J_{i}}{{BAG}_{i}} \rceil.}}}$

For each class I, the aggregate traffic has an input arrival curve inthe node n∈{es, sw}: α_(I) ^(n)(t)=min{C_(I,in) ^(n)·t, Σ_(i∈I,i∈n)α_(i)^(n)(t)}, where the maximum input rate C_(I,in) ^(n) is the sum of thecapacities C_(in) of the input links of node n crossed by traffic ofclass I, and α_(i) ^(n)(t) is the input arrival curve of flow i in noden. α_(i) ^(n)(t) is a staircase curve as illustrated in FIG. 8, withWCD_(prec) the delays in the previous nodes. We considered that in thegenerating node n, C_(I,in) ^(n)=+∞: (ii) the offered service curve bynode n to the traffic class I is a staircase curve as illustrated inFIG. 8. This results from using Th. 3 with staircase arrival curves.

Delay bound computation: with this method, we can use BCD_(fwd) ^(n) toobtain a tighter input arrival curve in the output port. The inputarrival curve of an aggregate flow I in the output port port in a noden∈{es, sw} is:

α_(i) ^(port)(t)=min{C _(I,in) ^(n)·(t+δ _(fwd) ^(n)),α_(I) ^(n)(t+δ_(fwd) ^(n))}

with δ_(fwd) ^(n)=WCD_(fwd) ^(n)−BCD_(fwd) ^(n). Then, according to Th.1, we can compute the worst-case delay bound as the maximum horizontaldistance between α_(I) ^(port)(t) and β_(I) ^(port)(t)=R_(I)^(port)·(t−T_(I) ^(port))⁺. The delay in the switch (or end-system) n isthen: WCD_(I) ^(n)=WCD_(I) ^(port)+WCD_(fwd) ^(n) and the output arrivalcurve is α_(I) ^(n,*)(t)=α_(I) ^(n)(t+δ_(fwd) ^(n)+WCD_(I) ^(port)).

End to end delay bounds: finally, the end-to-end delay of a flow isobtained by summing the delays along the path in the end-systems, inputports, switches and links along the path of the flow.

3.2 Case Study

We consider a real-world project AERO1⁷ depicted in FIG. 9, with 3end-systems, i.e., PG1, PG2 and PX2, and 3 switches, i.e., SW0, SW1,SW2. The forwarding delays are described in Table 1.1, and the linkcapacity is 100 Mbps. ⁷Please note that the realistic test cases havebeen anonymized due to contractual obligations

We consider 12 flows for TT (resp. RC) traffic, with a redundancy level3, i.e. 36 VLs, with identical period (resp. BAG) of 4 ins and MFS=1518bytes. The RC traffic has a default maximum initial jitter of 100 μs.Six VLs are generated in PG1 with PG2

TABLE 1.1 Forwarding delays Node n WCD_(fwd) ^(n) (s) BCD_(fwd) ^(n) (s)End System 2.43 · 10⁻⁶ 2.18 · 10⁻⁶ Switch 2.50 · 10⁻⁶ 2.41 · 10⁻⁶and PX2 as destinations. The other six are generated in PG2 with PG1 andPX2 as destinations. The default deadline of a flow is equal to theperiod.

In order to assess both methods, we explore different scenarios byvarying two parameters, i.e., the TT deadline and RC jitter, asillustrated in Table 1.2. As highlighted in the traffic model,increasing the initial jitter increases the input arrival curve of thegenerated traffic, resulting in the increase of the RC end-to-end delaysfor identical TT offsets. Consequently, increasing the RC jitter alsoincreases the constraints on the RC deadline and delay. We choose tovary the jitter because it is a minor parameter compared to MFS and BAG,allowing us to remain close to the default scenario.

The results of various scenarios will highlight the advantages anddrawbacks of each method.

We focus on the maximum number of iterations n_(max), on the maximumtime of execution t_(max), on the iteration where the best result isfound n_(best), on the time necessary to find the best result t_(best),and on the schedulability sched. We define the schedulability as thepercentage of schedulable flows. Additionally, to ensure the algorithmends within an acceptable time frame, we have added a constraint in Line7 of Algo. 1 to limit the number of iterations to 2 000.

TABLE 1.2 Scenarios description scenario TT deadline (s) RC Jitter (s)default 0.004 100 · 10⁻⁶ 1.1 0.004 800 · 10⁻⁶ 1.2 0.004 900 · 10⁻⁶ 1.30.004 1000 · 10⁻⁶  1.4 0.004 1100 · 10⁻⁶  1.5 0.004 1200 · 10⁻⁶  2.10.002 100 · 10⁻⁶ 2.2 0.002 300 · 10⁻⁶ 2.3 0.002 400 · 10⁻⁶

3.3 Results

First, we compute the results of all 9 scenarios without theoptimization methods, i.e., with the current implementation. Resultsshow that the computation is done in about t_(max)=1.80 s and that 18out of 36 RC VLs are not schedulable, i.e., their delay is greater thantheir deadline. Hence, the schedulability of RC flows is 50% without theoptimization methods for all 9 scenarios.

In Table 1.3, we present the results of the scenarios finding anacceptable solution, i.e., all the RC flows are schedulable.

In Table 1.4, we present the results of scenarios not finding anacceptable solution, i.e., not all the RC flows are schedulable.

TABLE 1.3 Results with a schedulability of 100% for both methodsscenario method n_(max) t_(max) (s) default 1 1 101 default 2 1 2.5 1.11 1 95 1.1 2 3 3 1.2 1 4 174 1.2 2 691 256 1.3 1 4 170 1.3 2 1110 5082.1 1 8 46 2.1 2 1 2.3 2.2 1 1841 3934 2.2 2 123 76

TABLE 1.4 Results without a schedulability of 100% for both methodsscenario method n_(max) t_(max) (s) n_(best) t_(best) (s) sched 1.4 1 55604 55 604 100% 1.4 2 2000 1190 1053 616  83% 1.5 1 2000 8621 1 115  50%1.5 2 2000 1180 1535 882  66% 2.3 1 2000 3968 255 891  83% 2.3 2 20001023 660 350  83%

First, concerning the default scenario, we can see from Table 1.3 thatboth methods find solutions after the first iteration (n_(max)=1).Hence, the schedulability is increased from 50% to 100%. Additionally,t_(max) shows that, as expected, method 2 is faster than method 1 (up to51 times faster in scenario 2.2), and slightly slower than the currentmethod without the optimization.

When studying all 9 scenarios, we notice that method 1 tends to find thebest solutions in less iterations (i.e. n_(max) and n_(best) inscenarios 1.1, 1.2, 1.3, 1.4, and 2.3), but not always (i.e. scenarios2.1 and 2.2). This is most likely due to the approximations done on thegain functions in method 2.

However, less iterations does not necessary result in better timingperformances (i.e. t_(max) and t_(best) in scenarios 1.1 and 2.3)because, as expected, an iteration with method 2 is faster than withmethod 1, e.g. about 4 times faster in scenario 2.3 and up to 40 timesfaster in the default scenario.

When the schedulability is not 100% with both methods (see Table 1.4),we can see that the best method, i.e. with the best schedulability,depends on the scenario: method 1 for scenario 1.4 and method 2 forscenario 1.5. This again highlights that either method can find the bestoffsets.

Also, it is interesting to compare the maximum time to explore all 2 000options: in scenario 1.5, it takes t_(max)=8621 s for the first methodto finish, and only 1180 s for method 2 to assess that no solution gives100% schedulability. Additionally, the schedulability with method 1.i.e., the longest to finish, is lower than with method 2, i.e., thefastest method.

Finally, we can conclude that while method 1 is less complex toimplement and generally finds results in less iterations, method 2 isthe best method to find solutions in an acceptable time frame.Additionally, we see that our feedback-based method is able to generateschedules for TT flows such that the schedulability of RC traffic isincreased for all 9 scenarios (even up to 100%).

We claim:
 1. A method for generating a schedule for the transmission oftime-triggered, TT, messages in a network comprising a TTEthernet or TSNnetwork, wherein the network comprises components comprising nodes andstarcouplers, wherein the components of said network communicatetime-triggered messages according to said schedule and based on aglobal, network-wide time, and wherein said components communicaterate-constrained, RC messages, wherein for each of said RC messagesreal-time requirements are provided, wherein the method comprises thesteps of: Step 1: setting the transmission time of all TT messages whichare communicated in the network, and Step 2 executing a search functionto find a set of TT transmission times so that real-time requirements ofall RC messages are fulfilled, and when all real-time requirements or atleast real-time requirements for defined RC messages are fulfilled,generating in Step 3: the schedule based on the transmission timesretrieved in Step 2, or executing Step 2 again in case that not allreal-time requirements or not all real-time requirements for the definedRC messages are fulfilled.
 2. The method according to claim 1, whereinthe transmission times of all the TT messages are set for one TT flowafter the other, using an optimization function with an SMT-solver. 3.The method according to claim 1, wherein the real-time requirements forthe RC messages comprise an end-to-end delay bound, and wherein thesearch function in Step 2 is loop based with the following loop-steps:loop-step 1: comparing the worst-case end-to-end delay bound of each RCflow with its corresponding deadline, wherein in case that the delaybound is larger than the corresponding deadline according to the RCrequirements for said RC flow, the next two loop steps are executed:loop step 2: identifying TT transmission times to be modified, and loopstep 3: computing of the transmission times of the selected TT flows inloop step 2 for each output port of the flow path of a selected TT flowusing an optimization function within the SMT-solver.
 4. The methodaccording to claim 1, wherein a record of the previously explored optioncan be kept, which may be used to guide the search into unexplored partsof the solution space and/or to be used as an additional stoppingcondition for the search.
 5. The method according to claim 1, whereinthe search function comprises the identification of TT transmissiontimes to be modified based on a Network Calculus framework and anarrival curve in each output port, which represents the maximum amountof data that can arrive in an output port in any time interval of TTtraffic detailed.
 6. The method according to claim 5, wherein astaircase curve for each output port of the network crossed by TT flowsis computed, and wherein the staircase curves are approximated by linearcurves, and wherein TT flows having a large impact on the real-timerequirements of the RC flows are identified by intersecting a staircasecurve and its linear approximation, the flow most likely to have a largeimpact on RC flows is identified.
 7. The method according to claim 1,wherein the computation of the TT transmission times is executed withthe use of an optimization function, which is added within theSMT-solver, and wherein a set of TT flows with a hyper-period, HP, whichis the least common multiple of all flow periods of all TT flows, isconsidered, and wherein for each output port, where TT flows occur, again function is defined.
 8. The method according to claim 7, whereinfor the computation of transmission times gain functions between thealready scheduled TT frames are determined, wherein with t_(end) ^(k)being the end of a frame transmission and t^(start) _(k+1 being) thestart of the next transmission, for each TT frame already scheduled, thegain functions are determined by:${\forall{t_{k}^{end} \leq t < \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t - t_{k}^{end}}}$${\forall{t_{k + 1}^{start} \geq t \geq \frac{t_{k}^{end} + t_{k + 1}^{start}}{2}}},{{{gain}(t)} = {t_{k + 1}^{start} - t}}$wherein for each period of a flow of interest in each output port, thegain functions are summed and the abscise of the maximum value of thesummed gains is selected by the SMT-solver as the transmission time inthe output port.
 9. The method according to claim 7, wherein only gainfunctions in the acceptable times are summed, and wherein the resultingsummed gain functions are approximated, in each output port, in that theabscise of the maximum value of the approximated gains is selected bythe SMT-solver, as the transmission time in the output port.
 10. Acomputer network comprising a TTEthernet or TSN network, wherein thenetwork comprises components comprising nodes and starcouplers, whereincomponents of said network communicate time-triggered messages accordingto a schedule and based on a global, network-wide time, and wherein saidcomponents communicate rate-constrained, RC messages, wherein for eachof said RC messages real-time requirements are provided, wherein theschedule is generated with a method according to claim
 1. 11. A computerprogram comprising program code for performing all steps of claim 1 whensaid program is run on a computer.
 12. A computer program productcomprising program code stored on a computer readable medium forperforming the method of claim 1 when said program product is run on acomputer.